🔍 向量資料庫 (Vector Database) 為何重要？

在 RAG 系統中，找到「語意最接近的知識片段」是核心，然而昨日文章有提到，要做語意檢索，其實是需要先做embedding，讓資料變成是向量，而要正確找到資訊還需要以向量做為索引來高維度向量檢索，而如何達到高速檢索，就是 向量資料庫重要之處。
與傳統關聯式資料庫（RDBMS）不同，向量資料庫專門設計用來處理 高維度向量檢索，支援相似度搜尋、Metadata 過濾，以及針對語言模型優化的索引機制。

📊 與一般資料庫的不同

⚙️ 向量資料庫的評估指標

在挑選向量資料庫時，可以透過以下幾個維度來衡量：

• RPS (Requests-per-Second)：每秒能處理多少請求，反映系統在多用戶情境下的效能。
• Latency (延遲)：單次請求的處理時間。
• p95 Latency (95% 延遲)：95% 的請求在多長時間內完成，更符合真實用戶體驗。
• Index time (索引時間)：建立索引的速度，特別重要在大規模資料匯入時。
• Precision (精確度)：檢索回傳結果與實際相關性的吻合程度。

🗄️ 常見向量資料庫的基本比較

因為我們的目的是要做地端部署，因此也要檢查是否是用於本地

🔎 向量資料庫的相似度檢索方式比較

在向量資料庫中，相似度檢索的核心是如何在「高維度空間」中找到與查詢最接近的向量。
大部分資料庫會採用 ANN (Approximate Nearest Neighbor) 技術，以在「速度」與「精確度」之間取得平衡。
因我們的需求是地端佈署，所以筆者整理幾個支援地端的向量庫資料供參考如下表:

支援地端之向量資料庫與檢索技術

🔑 補充說明

• HNSW (Hierarchical Navigable Small World)
  • Graph-based ANN 方法，目前是檢索速度和精度最均衡的選擇。
  • Qdrant、Weaviate、Milvus、Chroma 多半預設用 HNSW。
• IVF (Inverted File Index)
  • 把向量分到不同的 cluster，再在 cluster 內搜尋 → 適合大規模數據。
• PQ (Product Quantization)
  • 用壓縮向量降低記憶體與儲存成本，但精度下降。
• Flat / Exact Search
  • 完全精確搜尋，結果最準確但效能差（O(N)）。

筆者自己是以ChromaDB和Qdrant作為開發，兩個資料庫都有以下幾項優點:

• 支援 本地部署（Rust 開發，效能佳，Docker 部署簡單）
• 原生 metadata 過濾，可用於權限隔離、多租戶場景
• 設計理念貼近 企業應用（multi-tenant 支援）
• LangChain 官方支援（Qdrant class 已內建）

👉 對於企業級 RAG 系統，Qdrant 在 效能、靈活性、擴展性 上都是目前最平衡的選擇，ChromaDB則是對於小型專案可以快速開發，我們在這周實作先使用ChromaDB來實作，後面進階版本則會使用Qdrant，到時候可以一起比較一下兩者差異。